Qdrant's recommend API takes a set of positive example point IDs and a set of negative example point IDs and returns points that are similar to the positives and dissimilar to the negatives. For 'users who liked this also liked', the pattern is: for a given item, find the users who liked it, then use those users as positive examples to find other items they also liked. This is a collaborative-filtering-style recommendation expressed as vector similarity. Concretely, you have a collection of items with embeddings, and a collection of users with embeddings (or a mapping from users to the items they liked). To recommend items similar to a given item, you can either use the item's own embedding as a positive example, or use the embeddings of users who liked the item as positive examples and the embeddings of users who disliked it as negative examples. The recommend API returns items that are close to the positives and far from the negatives, which is exactly the collaborative filtering signal: 'items liked by people who liked this item, but not liked by people who disliked it'.

The mechanism is that the recommend API computes a query vector from the positive and negative examples by averaging the positives and subtracting the negatives (with weights), then runs a vector search with that query vector. The result is a set of points that are maximally similar to the positive examples and maximally dissimilar to the negative examples. This is more expressive than a simple 'find similar to this item' search because it can incorporate both attraction and repulsion. For a recommendation system, the positives are typically items the user has engaged with, and the negatives are items the user has explicitly disliked or dismissed. The recommend API can also be used with a strategy parameter to control how the examples are combined (average vector, best score, sum of scores), which affects the diversity of the results. The discovery API is a related but different mode: it takes a target and a context, and finds points that are similar to the target but constrained by the context, which is useful for 'find items like this but within this category' queries.

1
Recommend: positive and negative example point IDs -> items similar to positives, dissimilar to negatives.
2
Positive examples: items the user has liked, purchased, or engaged with.
3
Negative examples: items the user has disliked, dismissed, or explicitly rejected.
4
Strategy: average_vector, best_score, or sum_scores - controls how examples are combined.
5
Discovery: a target and a context - find items like the target within the context.
6
Limits: the number of examples and the result limit are configurable.
7
Filters: combine recommend with payload filters to restrict to eligible items.
8
Cold start: new items with no interactions need a content-based fallback.

The trade-off is between expressiveness and the availability of examples. The recommend API is more expressive than simple similarity but requires positive and negative examples, which are not always available, especially for new users or new items. For a new user with no history, the system falls back to popularity or content-based recommendations. For a new item with no interactions, the system cannot use it as a positive example until users engage with it. The common mistake is to use only positive examples and no negatives, which produces recommendations that drift toward the most popular items rather than toward the user's specific taste. The second mistake is to use too many examples, which averages out the signal and produces generic recommendations. The third mistake is to not filter out items the user has already seen or purchased, which wastes recommendation slots. The fourth mistake is to use the recommend API with examples that are not in the collection, which produces an error. Version note: the recommend and discovery APIs have evolved across Qdrant releases. Some versions require the example IDs to exist in the collection; others allow raw vectors as examples. The strategy parameter and its options may differ. The query_points API in qdrant-client 1.10+ unified several query modes, and the recommend call shape may have changed.

javascript

Version-dependent: the recommend and discovery APIs have changed across Qdrant releases. In qdrant-client 1.10+, the query API is unified under query_points, and the recommend and discovery modes are expressed as query types. In older versions, they were separate methods (recommend, discover). The strategy options and the ability to use raw vectors as examples may also differ. Verify the API shape for your version before implementing.

Difficulty: 7/10

Topics: Recommendations, Recommend API, Collaborative Filtering

Scenario Questions

0-2 years experience

1
You want to recommend items similar to what a user has liked. Describe the query and the examples you would use.
2
A teammate uses only positive examples. Explain why adding negatives improves the recommendations.

2-5 years experience

1
Your recommendations are too generic and drift toward popular items. Diagnose the cause and describe how you would fix it.
2
You need to exclude items the user has already purchased. Describe the filter and how you would apply it to the recommend query.

5-8 years experience

1
Design a recommendation system that combines the recommend API with business signals (popularity, recency, margin). Describe the retrieval and the reranking.
2
You need to serve recommendations for millions of users with low latency. Describe the caching and precomputation strategy.

8+ years experience

1
You are designing a recommendation system that must handle cold start, real-time signals, and diversity constraints. Describe the architecture and the evaluation.
2
Derive the trade-off between the number of examples used in the recommend query and the quality of the recommendations, and how you would optimize it.

Follow-up Questions

❓How would you choose the number of positive and negative examples for the recommend API, and how would you measure the quality of the recommendations?
❓How would you handle the case where a user has liked many items across different categories - would you use all of them as positives, or segment them?